Systems and methods for processing game metrics from handheld computing devices

ABSTRACT

A system for processing game metrics includes a handheld computing device and a game metric server. The handheld computing device captures the game metrics for a game and transfers the game metrics. The game metric server receives the game metrics from the handheld computing device via a computer system and a communication network and processes the game metrics.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 60/610,317 filed Sep. 15, 2004 and titled “Systems and Methods for Processing Game Metrics from Handheld Computing Devices” which is incorporated herein by reference.

BACKGROUND

1. Field of the Invention

The present invention relates generally to handheld computing devices, and more particularly to systems and methods for processing game metrics from handheld computing devices.

2. Description of the Prior Art

Video games have historically stored a list of high scores, so gamers can measure their own performance and their performance against other gamers. The list of high scores also provides a sense of competition between gamers and goals for gamers to achieve. Some arcade games are connected to a network, so an aggregate list of high scores can be displayed at each arcade game.

In one example of a video game called Zelda for console games, a user receives a code upon completion of the game. The user could then call an 800 number with the code to win a competition for the first to complete Zelda. Handheld gaming devices also keep high scores for certain games. For some games, a user receives a code from the handheld gaming device. The user then manually enters the code and the score at a website for a certain game. The website can then display a list of high scores for games on the handheld gaming device. One problem with this system is that there is no way to automatically generate a list of high scores for games on handheld devices.

SUMMARY OF THE INVENTION

The invention provides systems and methods for processing game metrics from handheld computing devices. A system for processing game metrics includes a handheld computing device and a game metric server. The handheld computing device captures the game metrics for a game and transfers the game metrics. The game metric server receives the game metrics from the handheld computing device via a computer system and a communication network and processes the game metrics.

The system for processing game metrics from a handheld computing device automatically transfers the game metrics to a game metric server that can manage and share game metrics such as high scores for games. Thus, players with a high score can let the world know of their achievement for a particular game and compare their abilities with other players around the world. Besides simple high scores lists, the system allows for development of time-dependent tournaments and competitive game ladders for games on handheld computing devices.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a system for game metrics in an exemplary implementation of the invention;

FIG. 2 is a flowchart for a handheld computing device executing a game metric reporting application programming interface in an exemplary implementation of the invention;

FIG. 3 is a flowchart for a computer system executing conduit software in an exemplary implementation of the invention; and

FIG. 4 is a flowchart for a game metric server executing game metric processing software in an exemplary implementation of the invention.

DETAILED DESCRIPTION OF THE INVENTION

The embodiments discussed herein are illustrative of one example of the present invention. As these embodiments of the present invention are described with reference to illustrations, various modifications or adaptations of the methods and/or specific structures described may become apparent to those skilled in the art. All such modifications, adaptations, or variations that rely upon the teachings of the present invention, and through which these teachings have advanced the art, are considered to be within the spirit and scope of the present invention. Hence, these descriptions and drawings should not be considered in a limiting sense, as it is understood that the present invention is in no way limited to only the embodiments illustrated.

The invention provides systems and methods for processing game metrics from handheld computing devices. Game metrics include any score, measurement, or status that indicates progress in a game. One example of a game metric is a high score for a game. The game metrics are transferred from the handheld computing device to a game metric server that manages and shares high scores for games. Thus, players with a high score can let the world know of their achievement for a particular game and compare their abilities with other players around the world. In one embodiment, the game metric is a type of score that is a 32 bit unsigned integer.

Other examples of game metrics are points, times, goals, and scores for tournaments. Game metrics may be organized by different score types, where each score type is treated as a totally independent score category. In some embodiments, a ‘normalized score’ is not displayed to the user via a high score manager or a website running on the game metric server. A formatted string accompanies each score and is displayed for the user. This provides flexibility to the applications to report scores in various ways such as times, points, kills, or goals. If a combination of variables is important to game play (e.g. best time and most kills and most secrets discovered), then the game can combine these values into one 32-bit value for comparison purposes. The string for the game metric can be formatted to describe different score attributes. The scorer for a given game can be considered to be the registered owner of the device. In some embodiments, there is one date included for each high score record.

FIG. 1 depicts an illustration of a system 100 for game metrics in an exemplary implementation of the invention. The system 100 includes a handheld computing device 110, a computer system 120, a communication network 130, and a game metric server 140. The handheld computing device 110 is coupled to the computer system 120. The computer system 120 is coupled to the communication network 130. The communication network 130 is coupled to the game metric server 140. The elements in FIG. 1 can be coupled together by either wired or wireless connections.

The handheld computing device 110 is any handheld device that includes a processor for executing instructions and is configured to capture the game metrics for a game and transfer the game metrics to the computer system 120. Some examples of the handheld computing devices are handheld gaming devices, personal digital assistants, and mobile phones. One embodiment of the handheld computing device 110 is the Zodiac gaming device from Tapwave of Mountain View, Calif.

The handheld computing device 110 includes a game metric reporting Application Programming Interface (API) 115. In some embodiments, the game metric reporting API 115 can be any other type of software program operating in accord with the invention. The operation of the handheld computing device 110 executing the game metric reporting API 115 is described in further detail below in FIG. 2.

In some embodiments, the game metric reporting API 115 includes a high score manager configured to store all the high scores for all games on a given device. In some embodiments, each application on the handheld computing device 110 can control how many high scores are saved.

The computer system 120 is any computer with a processor for executing instructions and that is configured to transfer game metrics from the handheld computing device 110 to the game metric server 140 via the communication network 130. The computer system 120 includes conduit software 125 for synchronization to transport the data between the handheld computing device 110 and the game metric server 140. The operation of the computer system 120 executing the conduit software 125 is described in further detail below in FIG. 3. In some embodiments, the conduit software transmits only the highest local score per game and score type to the game metric server 140.

The communication network 130 is any network of communication devices. Some examples of the computer network 130 are the Internet, PSTN, local area network, and wide area network.

The game metric server 140 is any system or server configured to receive and process game metrics from the handheld computing device 110. In some embodiments, the game metric server 140 includes a web front end to sort, filter, and display the high score data. The game metric server 140 includes game metric processing software 145. The operation of game metric server 140 executing the game metric processing software 145 is described in further detail below in FIG. 4.

FIG. 2 depicts a flowchart for the handheld computing device 110 executing the game metric reporting API 115 in an exemplary implementation of the invention. FIG. 2 begins in step 200. In step 202, the handheld computing device 110 executing the game metric reporting API 115 captures scores from game software running on the handheld computing device 110.

In step 204, the handheld computing device 110 generates a master record for score type and game. The high score manager also allows each game to include a 32 bit “checksum” value with each score, which can be used to validate that the score was actually achieved during game play, and not simply added to the database using, for example, PalmOS APIs. It would be up to the game developer to decide how to generate and validate the checksum, and conspire with the web site developer to filter scores that fail checksums. Checksums assist with integrity of the game metrics because some game players may be tempted to get higher scores by either hacking the game or hacking the score reporting mechanism.

In some embodiments, all high score data is stored in a single record database, with the records laid out in a 68K (big-endian) format. The high score database can be a record database, with the name “High Scores”, the creatorID ‘twHS’, and the data manager type ‘DATA’. The creatorlD associates the high score database with a dummy “High Score” application, which is embedded in the ROM of the handheld computing device 110, always present, and thus should always allow the conduit software to run. The high score database has an applnfo structure which should contain the following information: TYPE (size) Field Name Field Description Int32 (4) syncWithServer If non-zero, the conduit should attempt connections to the server. Chars (16) deviceSerialNum The 16 digit base-34 device serial number, read from the hardware. This is just a copy of the serial number, and it will be validated (and changed if necessary) during normal device operations. UInt32 (4) serverSyncTimeUTC Time in seconds since midnight Jan. 1, 1904 in the UTC time zone that the server sync was last completed. 0 if never synced. Char* Alias The alias used by the user on the (var) Tapwave website, created at registration, cached here for use by games.

There are two types of records stored in the database, a ‘master’ record for each combination of score type and game, and one ‘score’ record for each saved score. Both the server pool and the local pool use the same record format. Both the master record and score records have the same format for the first 3 fields, which aids sorting.

The database is maintained in sorted order for efficient access. Overall the records are kept sorted by creatorID and scoreType, so that all records for a given game/type combination will sort together. Within this set, the master record is always first (and always present if any scores are present), followed by 0 or more local scores and then 0 or more server scores. The following table illustrates one embodiment for the master record. Type (Size) Field Name Field Description UInt32 (4) CreatorID The unique, registered creatorID of the game. UInt16 (2) ScoreType The arbitrarily chosen type identifier for this score. UInt16 (2) RecordType Identifies a master record (and sorts first). MASTER_ID = 0 UInt16 (2) numLocalScoresToKeep An integer that specifies how many scores to keep in the local pool for this game. UInt16 (2) numServerScoresToKeep An integer that specifies how many scores to keep in the local pool for this game. UInt16 (2) reportScoresToServer TRUE (1) to report scores to server for this game and score type, FALSE(0) to not report scores to server. Char* (var) GameName The rest of the record is character data that contains the user-visible name of the game for the High Score manager.

In step 206, the handheld computing device 110 generates a score record for the saved score. The following table illustrates one embodiment for the score record. Type (Size) Field Name Field Description UInt32 (4) CreatorID The unique, registered creatorID of the game. UInt16 (2) ScoreType The arbitrarily chosen type identifier for this score UInt16 (2) RecordType The record type, 1's for local scores and 2's for LOCAL_POOL = 0x1111 server scores. All the local scores come before SERVER_POOL = 0x2222 any server scores. UInt32 (4) Score The normalized score value. UInt32 (4) Checksum A checksum, used to validate the score value. UInt32 (4) timeAndDateUTC The date and time that the score was reported, as time in seconds since midnight Jan. 1, 1904 in UTC. Char* userString The (null-terminated) string that goes with the (var) score. For server scores, the user string is prefixed with the alias of the scorer followed by the tab character.

In step 208, the handheld computing device 110 stores the master record and the score record for synchronization between the handheld computing device 110 and the computer system 120. In step 210, the handheld computing device 110 determines whether synchronization is occurring. If there is no synchronization, the handheld computing device 110 proceeds to step 214. If synchronization is occurring, the handheld computing device 110 transmits the master record and the score record to the computer system 120 in step 212. FIG. 2 ends in step 214.

FIG. 3 depicts a flowchart for the computer system 120 executing the conduit software 125 in an exemplary implementation of the invention. FIG. 3 begins in step 300. In step 302, the computer system 120 executing the conduit software 125 determines whether synchronization is occurring between the handheld computing device 110 and the computer system 120. If synchronization is not occurring, the computer system 120 proceeds to step 318. If synchronization is occurring, the computer system 120 receives the master record and the score record from the handheld computing device 110. The conduit software 125 transfers all scores from the handheld computing device 110, effectively backing up the high score records. Any records deleted on the handheld computing device 110 will also be deleted on the computer system 120.

In step 306, the computer system 120 then determines whether the score from the master record and the score record is the high score. If the highest score for a given master record (game+scoreType combination) is new, then the score needs to be transmitted to the game metric server 140. If the score is not a high score, the computer system 120 proceeds to step 318.

If the score is a high score, the computer system 120 then checks whether the sync with server flag is set in step 308. The conduit software 125 checks an “opt in” setting stored on the handheld computing device 110. Server connections will only be attempted if the user has enabled them, by setting the appropriate flag on the handheld computing device 110. If the sync with server flag is not set, the computer system 120 proceeds to step 318. If the sync with server flag is set, the computer system 120 determines whether the server is enabled for a game and score type in step 310. If the server is not enabled for a game and score type, the computer system 120 proceeds to step 318.

If the server is enabled for a game and score type, the computer system 120 determines whether a connection is established to the game metric system 140 via the communication network 130 in step 312. In some embodiments, the connection to the game metric server 140 needs to be live during synchronization for the transaction to take place. In one example, if the computer system 120 is not connected to the Internet at the time of synchronization, or if the server is unresponsive, then the data is not transferred. In this example, the user needs to synchronize again to re-attempt the connection. During a handheld computing device 110 restore, all records should be restored to the handheld computing device 110 during synchronization. In some embodiments, conflict rules are fixed: the handheld computing device 110 overrides the computer system 120 for game master records and local scores, the computer system 120 overrides the handheld computing device 110 for server based scores.

If a connection is established, the computer system 120 transmits the game metrics to the game metric server 140 in step 314. If a connection is not established, the computer system 120 stores the master record and the score record for future synchronizations in step 316.

In one embodiment, the game metrics that are transferred to the game metric server 140 are in an Uniform Resource Locator (URL) format. In this embodiment, game score submission consists of sending a URL with specified name/value parameters in the query string to the game metric server 140 that describes a score for a particular game played on the user's device. The server component that handles this request can be a Java Servlet. The Servlet should be written such that either an HTTP Post or HTTP Get message of the specified URL will be handled in the same manner. In other words, the doGet( ) and doPost( ) methods of the Servlet should be written to call the same logic. An exemplary URL and appropriate parameters are described below: Example URL: http://hsupload.tapwave.com/desktop/reportScore/?hardwareID=0T000139C111601J&cr eatorID=0x54574853&scoreType=1001&score=1000&checksum=0x000003e8&recorde d=1067899622000&userString=1000%20points Name Data Type Description hardwareID A 16 digit base-34 value A unique value that identifies the hardware “0T000139C111601J” device. This value comes from the Road Dawg hardware ROM. creatorID 32 bit unsigned hex integer A 4-byte value that unique defines an “0x00000000 . . . 0xFFFFFFFF” application developer. While this value is most likely a 4 letter value (e.g. DOOM, ADDR) its representation it is still defined as an integer. The CreatorID is also assigned by Palm. scoreType 16 bit unsigned decimal A value used to define which game type integer this score is associated (used primarily for “0 . . . 65535” game tournaments to identify a score being submitted for a tournament). score 32 bit unsigned decimal A numerical value that describes a score integer achieved for a particular game. “0..4294967295” checksum 32 bit unsigned hex integer Used to verify a score was created on a “0xFFFFFFFF” device, rather than a faked score. Currently not evaluated on the server. recorded 64 bit unsigned decimal A numerical value that defines when the Long high score was achieved on the device. “10678996222000” This value is the number of milliseconds since the Epoch (Jan. 1, 1970 00:00:00) in GMT. userString (escaped) String Provides a user friendly display format for “1000% 20Points” the high score

Whether or not this is a high score for the game (for this user) is determined by the game metric server 140. The information is recorded that this particular user has played a particular game and achieved a score. If the game metric server 140 determines that the score is a high score (for this user) for the game, it will be stored in a high score repository.

The scoreType value will be used to relate a score to a particular tournament being played. The checksum value is used as a further check to verify the integrity of the score being submitted. Ultimately, the checksum value will be used to ensure that the score is genuine. The recorded parameter is used to timestamp when the high score was achieved. It should be sent as a long value, which contains the number of milliseconds since the Epoch (Jan. 1, 1970 00:00:00) in UTC (i.e. GMT).

The userString value defines a displayable format for scores and is used on the Zodiac/Zorro device. This value should be stored within the server database for a high score. There can be characters within the string that may have to be escaped when sending back to the client (e.g. a space needs to be converted into %20). FIG. 3 ends in step 318.

FIG. 4 depicts a flowchart for the game metric server 140 executing the game metric processing software 145 in an exemplary implementation of the invention. FIG. 4 begins in step 400. In step 402, the game metric server 140 executing the game metric processing software 145 receives the game metric in the URL format from the computer system 120 via the communication network 130.

In step 404, the game metric server 140 determines whether the score is the high score for the user ID, game creator ID, and score type. If the score is not the high score, the game metric server 140 proceeds to step 410. In some embodiments, the game metric server 130 stores all score data (as defined above) for only the highest score for each combination of: user ID (looked up from device serial number)+game creatorID+game scoreType. If a higher score with matching user ID, creatorlD and scoreType is sent, the existing record is replaced with the new higher record.

In some embodiments, the algorithm for taking into account whether a new score belongs in the high score table includes the following:

-   -   Verifying that the new score is better than the current score         achieved by this user for this game. This is done by comparing         the unsigned 32 bit values. Higher values are typically better.     -   If a game high score is submitted to the server, and that game         cannot be found in the high score database, then the assumption         is made that this is a new game and the score is entered as the         current high score for this user.     -   The checksum value associated with a high score is stored in the         database.     -   The scoreType value associated with a high score is stored in         the database. The scoreType value can be used for tournaments.

If the score is a high score, the game metric server 140 stores the master record and the score record in step 406. In step 408, the game metric server 140 stores the checksum value for future validation.

In step 410, the game metric server 140 transmits an Extended Mark-up Language (XML) response back to the computer system 120 indicating the status of the high score submission. The response to the score submission may be an XML-formatted message that provides status for the operation. One field will describe the message status. A description field will provide more detailed information about what happened. For example: <?xml version=1.0 encoding=”ISO-8859-1”?> <highscore> <status>100</status> <description>A new high score for Tony Hawk was registered </description> </highscore> Or <?xml version=1.0?> <highscore> <status>104</status> <description>All data in the database was corrupted - ouch</description> </highscore>

A successful high score submission to the game metric server 140 returns in the HTTP sponse header the status value of 200 (which is the well known value returned by HTTP servers for a success request operation). In this case, the XML-formatted response will exist. In the event of a server error, the status code of 500 (Internal server error) will be returned, and no XML-formatted response message will exist.

In the case of a successful request operation, the status field within the XML response message will describe what took place on the game metric server 140 when this high score submission was made. The value of this field is numeric, and can take on the following values: Status value Description 100 A score did not exist for this user and game; therefore a new high score was added into the high score database. 101 A score did exist for this user and game, and the submitted score is higher; therefore the existing high score was updated. 102 A score did exist for this user and game, and the submitted score is not higher; therefore the existing high score remains. 103 The specified user (identified by the SecurityID value) does not exist within the system. No high score was added to the system. 104 A general error occurred while parsing the input parameters

In step 412, the game metric server 140 displays the high score for a creator ID and score type.

For tournaments, the games on the handheld computing device 110 can have a play mode that is validated for tournaments. In this play mode, cheats are disabled, and as much as possible the game experience is normalized to that scores on different devices can be compared. The resulting scores are reported as a new scoreType for the same game.

A tournament can be run on a server by looking specifically for high scores from the given game and game type, reported within a particular time range, and generated on the handheld computing device 110 within a particular time range. For tournament play, special attention should be given to the checksums for the scores.

For social policing of high scores, similar features such as “block” and “warn” for instant messaging can be implemented in the game metric server 140. This would allow the customers to self-police, claming that scores for a given user are phony. Since scores are necessarily tied to the device serial number which is associated with a registered account, the names of people that may be cheating can be registered, which would discourage from making fake high scores. The threat of disabling all high score posting for a given account can be used to further dissuade people from making up fake scores.

In step 414, the game metric server 140 receives a high score request. In some embodiments, an application on the handheld computing device 110 requests that a certain number of highest scores can be retrieved from the game metric server 140, which depends on other variables such as whether the user is registered with the website and how often the user synchronizes. If enabled, the conduit software 125 queries the game metric server 140 for the top N high scores for each game and score type, and the existing server score records on the handheld computing device 110 is replaced with the new scores from the game metric server 140.

In some embodiments, the userString for the high scores is prefixed with the alias that corresponds to the original high score, followed by the tab character. For example, if device A reports a high score as “100 points”, and is registered to “Mad Bob”, the game metric server 140 reports the high score with the user string “Mad Bob\t100 points”.

The table below provides information about data types that are relevant for the high score API's. Along with the name of the data, its type information and a brief description of what the information is will also be given. Example URL: http://hsupload.tapwave.com/desktop/listGameScores/?scores=5&creatorID=0x54574853 &scoreType=0 Name Data Type Description HardwareID A 16 digit base-34 value A unique value that identifies the hardware device. This value comes from the Road Dawg hardware ROM. CreatorID 32 bit unsigned hex integer A 4-byte value that unique defines an “0x00000000 . . . 0xFFFFFFFF” application developer. While this value is most likely a 4 letter value (e.g. DOOM, ADDR) its representation it is still defined as an integer. The CreatorID is also assigned by Palm. ScoreType 16 bit unsigned decimal A value used to define which game type integer this score is associated (used primarily for “0 . . . 65535” game tournaments to identify a score being submitted for a tournament). Scores Integer A value used to limit the number of scores “0 . . . 32767” for a game returned. A practical maximum value is the largest signed 16 bit number, which is the maximum number of records that can exist in a PalmOS database.

Requests for game scores can be made on the server, which will return the information as an xml-formatted message. One embodiment for the format of the request for game scores is defined as follows: <?xml version=1.0 encoding=”ISO-8859-1”?> <games list=”1”>   <game title=”Doom”>     <highscores list=3>       <highscore>         <displayName>ray</displayName>         <score>50000</score>         <scoreType>1</scoreType>         <checksum>0</checksum>         <userstring>xxx:xyzzy</userString>         <recorded>1058470322000</recorded>         <submitted>1058470322000</submitted>       </highscore>       <highscore>         <displayName>bob</displayName>         <score>45000</score>         <scoreType>1</scoreType>         <checksum>0</checksum>         <userstring>xxx:xyzzy</userString>         <recorded>1058470322000</recorded>         <submitted>1058470322000</submitted>       </highscore>       <highscore>         <displayName>neal</displayName>         <score>44550</score>         <scoreType>1</scoreType>         <checksum>0</checksum>         <userstring>xxx:xyzzy</userString>         <recorded>1058470322000</recorded>         <submitted>1058470322000</submitted>       </highscore>     </highscores>   </game> </games>

In step 416, the game metric server 140 transmits the high scores in an XML formatted message. FIG. 4 ends in step 418.

The above-described functions can be comprised of instructions that are stored on storage media. These instructions can be retrieved and executed by a processor. Some examples of instructions are software, program code, and firmware. Some examples of storage media are memory devices, tape, disks, integrated circuits, and servers. The instructions are operational when executed by the processor to direct the processor to operate in accord with the invention. Those skilled in the art are familiar with instructions, processor, and storage media.

Those skilled in the art will appreciate variations of the above-described embodiments that fall within the scope of the invention. 

1. A system for processing game metrics, the system comprising: a handheld computing device configured to capture the game metrics for a game and transfer the game metrics; and a game metric server configured to receive the game metrics from the handheld computing device via a computer system and a communication network and process the game metrics.
 2. A method for processing game metrics, the method comprising: capturing the game metrics for a game into a handheld computing device; transferring the game metrics from the handheld computing device; receiving the game metrics into a game metric server from the handheld computing device via a computer system and a communication network; and processing the game metrics in the game metric server. 